Pass your certification exam. Faster. Guaranteed.

Change Control Transcription

Welcome to our change control module. Change control is a change management plan where changes are proposed, accepted, monitored, tested, and controlled with formal planning. If you do not have a formal change control process in place, a project can take much longer than appropriate to complete. Frustration can occur among all of the parties that are working on the project when changes occur.

The viability of any change request should be considered before the change is processed. You should formally record the change request by submitting a ticket. Engineers should evaluate the business need of the change, the feasibility of implementing it, and the level of effort that will be required. You should also estimate the costs and remember that time equals money before the changes can be approved.

The logic of the decision to request a change should be separated from the change control process, and this is done by using a change control board, or a CCB. The changes must be submitted to the change control board, who is responsible for determining at a formal meeting, whether or not the change should be tested, recorded, and approved.

They also need to establish new baselines and metrics. If the change control board approves the change, the security architect will have to redesign the project plan. Applications should be centrally stored and managed and security controls must always be protected. In order to maintain integrity, programmer changes should be made through controlled libraries.

Any changes that will be made should be made to the source code itself and not to the existing production code. For the CISSP examination, you should remember that changes are never made to the production code of software that is currently in use, rather, they should be made to the source code, and then pushed out to the program.

Your change management plan, or policy, controls changes by using a formal process. Changes can affect the scope of your project, including your deliverables, goals, deadlines, tasks, and probably, most importantly, your customer satisfaction. The change management plan should include the identification and inventory of any change requests, the analysis and documentation of the impact of these changes, whether or not the changes were approved or rejected, tracking the changes, and updating your project documentation to account for these changes that were approved, and also how you will notify the stakeholders of the changes.

Here we have a sample change control procedure. The first step is to request for a change ticket to be recorded into the change management system. Next, engineers will analyze and report on the requested changes. They will evaluate the feasibility and also make sure there is a need for this change to occur, they will develop a tentative implementation strategy, calculate the cost of the implementation, and also review the impacts, including any security implications or risks that this change could cause.

Next, they will record the change request, along with their analysis report, and then the change request will be submitted to the change control board for approval. If the change control board approves the change, you will need to develop change implementation, and then re-code different segments of the product to modify its functionality so that you can provide the solution that has been requested.

Next, you will link these changes in the code to the formal change control request and approval. Step eight is to submit the software for testing and quality approval. Next, you will continue to repeat your unit testing and integration testing until the quality is acceptable. And you should have a separation of duties here, where the testing is being done by someone other than the programmer who is creating the changes.

Number ten, you will make and record your new version number, then you will report the change success to your management. Finally, you will establish a baseline setting for this version against which all of your future changes can be measured. For the CISSP examination, you should remember that until the quality is at an acceptable level, you will continue to repeat the unit and integration testing over and over.

You should also remember that separation of duties is critical and that you should not have your programmers, who are designing the software, also conducting the testing. This concludes our change control module. Thank you for watching.